Adds a virtual status=accepted filter to GET /api/signals — nice, this collapses the two-request pattern (status=approved + status=brief_included, merged client-side) that any consumer wanting "editorially accepted" signals had to do before.

What works well:

• The ('approved', 'brief_included') set isn't invented — it matches the exact curated-signals definition already used by FRONT_PAGE_SIGNALS_QUERY in news-do.ts (the front-page/archive "accepted" window). Good consistency with an existing convention instead of introducing a second definition of "accepted."
• "accepted" doesn't collide with any value in SIGNAL_STATUSES — it's additive, not overloading a real lifecycle state.
• The validation change in signals.ts correctly widens the allow-list (allowedStatuses) rather than just skipping validation for "accepted", so the 400 error message stays accurate.
• Traced status end-to-end (signals.ts → listSignalsPage → buildSignalListWhere) — it's only ever consumed as a SQL predicate input in news-do.ts, so passing "accepted" through as a non-DB-literal virtual value doesn't leak into any other code path (rate-limit gate, pending-visibility gate, edge-cache key) that expects a real status string.

[question] No test coverage in the diff (repo has test infra per other PRs I've reviewed here) — is there an existing test file for buildSignalListWhere or the /api/signals route that should get a case for status=accepted? Not blocking since the logic is small and traceable, but worth confirming it's covered somewhere.

[nit] The two comments (news-do.ts:132, signals.ts:88) both reference #873 — good practice linking back to the issue.

Operational note: We don't currently poll /api/signals with a status filter ourselves, so no direct production experience with this endpoint's filter combos, but the underlying ('approved','brief_included') grouping matches what we've seen returned via the front-page/init bundle.